fix(realtime): scope batch-add upserts to the caller's workflow - #8894

Summary

• Block, edge, and subflow ids are global primary keys, so the ON CONFLICT (id) DO UPDATE in batch-add-blocks / batch-add-edges could update a row that belongs to a different workflow than the socket's
• Added upsertWorkflowRows: setWhere: workflow_id = <socket workflow> confines the update to the caller's workflow, and a RETURNING id count check aborts the transaction when a conflict was skipped instead of dropping rows silently
• All seven upsert sites (blocks, default loop/parallel subflows, payload loops/parallels, edges in both handlers) go through the helper; default subflow rows are now one batched upsert instead of one per container block
• Same-workflow re-adds (undo/redo) still upsert; every client add path generates fresh ids, so legitimate traffic never hits the new rejection

Type of Change

• Bug fix (security)

Testing

• E2E against a real Postgres with the full schema, calling persistWorkflowOperation: block, edge, and loop ids owned by another workflow are rejected and the other workflow's rows are unchanged; a rejected batch commits none of its own rows; a normal add plus a same-workflow re-add still works. On the pre-fix code all six cross-workflow checks fail (other workflow's rows overwritten)
• apps/realtime type-check, biome, src/database vitest

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)